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Prufungsantrag gem. § 44 PatG ist gestellt 

(g) Verfahren und Anordriung zur Durchfuhrung von Uberwachungs- und Managementfunktionen in Netzen mit 
iiberwachten Komponenten 

@ Eine Bereitsteilungseinheit (C & CM) ermoglicht es, die 

einfachen, aus Name und Wert bestehenden Objekte in 

eine relationale Datenbank (REL-DB) einzulesen, so da(^ 

Applikatlonen sich durch Auswahlbefehle (SQL-SELECT) 

der SQL-Sprache Informationen gemaR ihrem Bedarf - 

auch Komponenten uberschreitend • zusammenstellen 

lassen konnen. Dadurch da(^ auch die Beschreibung (ME- 

TA-DATA) der einfachen Objekte aus einer Datei (MIB-i-) in 

die relationale Datenbank (REL-DB) eingelesen werden 

und dadurch die Bereitsteilungseinheit (C & CM) steuern, 

kann die Realisierung vollig unabhangig von den Defini- 

tionen der einfachen Objekte sein. Den Objektdefinrtionen 

kann ein Attribut als weitere Steuerungs^nktion zur Be- 

einflussung der Bereitsteilungseinheit (C & CM) bezuglich 
■ der Zurverfugungsstellung der fur einen Auswahlbefehl 
I (SQL-SELECT) bendtigten Managementdaten (MGMT- 
> DATA) beigefugt werden. 
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Beschreibung 

Die Erfindung betrifft ein Verfahren und eine Anordnung 
zur Durchfuhrung von Uberwachtings- und Management- 
funktionen in Netzen mit iiberwachten Komponcnten, wo- 5 
bei die iiberwachten Komponenten uber einfache Objekte 
iiberwacht/gesteuert werden, wahrend die Management- 
funktionen auf beliebig daraus zusammengesetzten Infor- 
mationen basieren. 

Mit der zunehmenden Vemetzung von Rechnern wurde es lo 
notig, sowohl die Rechner ais auch die anderen Komponen- 
ten des Netzes zu uberwachen und gegebenenfalls zu steu- 
em. Dieses Netz-/Systemmanagement wurde im Prinzip mit 
folgenden Einrichtungen durchgefuhrt: Eine Administrator- 
konsole, die auch in Software realisiert sein kann, kommu- 15 
niziert mit Agenten (Software) auf den zu iiberwachenden 
Komponenten. Die Agenten liefem auf Anforderung Infor- 
mationen, wie Temperatur, Rechnerauslastung usw., an die 
Administratorkonsole. Die Administratorkonsole stellt 
diese Informationen dar, woraufhin der Administrator gege- 20 
benenfalls Aktionen auf den Komponenten starten kann. 
Dabei wird durch die Eingaben des Administrators an der 
Konsole eine Nachricht an den Agenten der entsprechenden 
Komponente gesandt, der dann entsprechende Verandenin- 
gen an der Komponente durchfuhrt. 25 

Ursprunglich wurden fiir die Realisierungen solcher Ma- 
nagement-Losungen proprietare ProtokoUe und proprietare 
Schnittstellen verwendet. Seit mehr als fiinf Jahren steht das 
sogenannte "Simple Network Management Protocol" als ge- 
normtes Protokoll SNMP fiir die Realisierung von Manag- 30 
ment-Applikationen zur Verfugung. Ein Oberblick iiber 
SNMP wird zum Beispiel in G. Kronert, Erweiterbarkeit 
von SNMP-Agenten, Teil 1: SNMP und SNMPv2, unix/ 
mail 12 (1994) 1, S. 20-24 gegebea - 

Dabei stellte sich heraus, daB im Prinzip keine wesentli- 35 
chen Unterschiede zwischen Netz-, System-, Gerate- oder 
Applikationsmanagement bestehen. In alien Fallen muB In- 
formation zwischen der iiberwachten Komponente und der 
Administratorkonsole ausgetauscht werden. Die iiberwachte 
Komponente kann daher ein Gerat, ein Rechner oder eine 40 
Applikadon sein. 

Fig. 1 zeigt das Prinzip einer SNMP-basierten Manage- 
mentlosung. Dem Administrator steht die Administrator- 
konsole ADMIN-KON zur Verfugung. Wahlt er in dem so- 
genannten User Interface UI eine in der Management- App- 45 
Ukation MGMT-APPL implementierte Funktion aus, so 
mu6 die Abbildungskomponente MAP die von dieser Funk- 
don benotigten Daten auf einfache SNMP-Objekte abbilden 
und iiber den ProtokoUstack SNMP-PrSt von der iiberwach- 
ten Komponente anfordem. Auf der uberwachten Korapo- 50 
nente U-KOM lauft ein Agent. Dieser besteht aus dem Pro- 
tokoUstack SNMP-PrSt und der Instrumentierung INST, die 
auf die Daten der Komponente U-KOM zugreift. Von der In- 
strumenderung INST laufen die Daten dann auf diesem Weg 
wieder zuriick zur Konsole ADMIN-KON, wo sie dann wie- 55 
der von der Abbildungskomponente MAP zu der von der 
Management- Applikadon MGMT-APPL benotigten Infor- 
mation zusammengestellt werden. Das User Interface UI 
stellt die Daten dann graphisch dar. 

SNMP transportiert einfache Objekte, die durch Name 60 
und Wert beschrieben werden. SNMP ist flexibel verwend- 
bar, weil die Objekte, die iibertragen werden, nicht genormt 
sind, sondem in sogenannten Management Information Ba- 
ses MIB formal beschrieben werden. Die Semantik der Ob- 
jekte ist verbal beschrieben. Soli zum Beispiel ein neues Ge- 65 
rat iiber SNMP iiberwacht und gesteuert werden, so mu6 
eine entsprechende MIB definiert sein. Die MIB beeinfluBt 
deshalb die beiden Module Instrumentierung INST und Ab- 
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bildungskomponente MAP, d. h. zur Unterstiitzung einer 
neuen MIB miissen diese Module neu entwickelt werden. 

Die Abbildungskomponente MAP erfiillt hauptsachlich 
zwei Aufgaben: 

- Zahlreiche einfache, iiber SNMP empfangene Ob- 
jekte mussen fur die Managementapplikation MGMT- 
APPL zusammengestellt werden, damit sie dann als 
Tabelle, Formular, Charts usw. dargestellt werden kon- 
nen. Dabei werden oft Daten, die in verschiedenen 
MLBs definiert sind, auf dem gleichen Bildschirm dar- 
gestellt, Auch miissen von der Abbildungskomponente 
MAP die Daten fiir verschiedene Funktionen der Ma- 
nagementapplikationen MGMT-APPL in der Regel un- 
ter schiedlich zusammengestellt werden; fiir die Uber- 
wachung auf der Konsole durch den Administrator 
miissen die Daten anders zusammengestellt werden als 
fiir die Erzeugung eines Reports. 

- Um die Netzbelastung gering zu halten und um die 
Antwortzeiten an die Administratorkonsole ADMIN- 
KON zu verbessem, ist es zweckmaBig, Daten - soweit 
moglich - in der Abbildungskomponente MAP zwi- 
schenzuspeichem. Kandidaten fur dieses Zwischen- 
speichem sind z. B. Konfigurationsdaten, die sich nach 
dem Hochfahren des Rechners nicht mehr andem, oder 
Daten, die im laufenden Beuieb erzeugt werden und 
sich nicht mehr andem, wie Log-Messages, Fehlermel- 
dungen oder Statistiken. 

Bei bisherigen Losungen sind diese Aufgaben durch die 
Realisierung der Module fur die Abbildungskomponente 
MAP und fiir die ManagementappUkationen MGMT-APPL 
in einer Programmiersprache gelost worden. Lediglich sog. 
MIB-Browser konnen zwar automatisch aus der MTR er- 
zeugt werden, jedoch konnen sie die in der MTB definierten 
Daten nur 1 : 1 tabellarisch darstellen, so daB fur MIB- 
Browser kein MAP-Modul benotigt wird. Ein beliebiges 
Zusammenstellen und Verknupfen der Daten ist deshalb 
nicht moglich. 

Neuere Ansatze befinden sich derzeit in der Erprobung. 
Sie sind dadurch gekennzeichnet, daB sie Modelle mit kom- 
plexen Objekten verwenden. Im Gegensatz zu einfachen 
Objekten, die nur durch Name und Wert beschrieben wer- 
den, haben komplexe Objekte Attribute mit Werten, aus- 
fuhrbare Methoden, Beziehungen zu anderen Objekten, und 
sie sind Exemplare von Klassen. Zwei derartige Ansatze 
werden zur Zeit entwickelt und erprobt: Java Management 
API (JMAPI) und Web-based Enterprise Management 
(WBEM). Information uber JMAPI und WBEM stehen im 
Web zur Verfugung unten 

- http:/j^ava. sun.com/products/JavaManagement/do- 
cuments/architecture/html/jmapi-arch.html (JMAPI) 

- http://wbem.freerange.com/wbempdk (WBEM). 

Fig. 2 zeigt diese Architektur am Beispiel von WBEM. 
Da SNMP breite Akzeptanz gefunden hat und bereits einige 
Zehntausend SNMP-Objekte in Hunderten von MEBs defi- 
niert sind, miissen diese Investitionen auch bei den neuen 
Ansatzen integrierbar sein. Deshalb wird auch in diesen An- 
satzen uber SNMP auf die iiberwachten Komponenten U- 
KOM zugegriffen. 

Die zentrale Komponente dieses Ansatzes ist der Objekt- 
Manager OBJ-MGR (bei WBEM: HMOM (Hypertext Ma- 
nagement Object Manager, bei JMAPI: Managed Objects 
Factory). Die komplexen Objekte eina: Managementiosung 
werden von einem festgelegten Informationsmodell, dem 
sogenannten Conunon Information Modell CIM abgeleitet. 
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Es definiert die Klassen der oberen Ebenen einer Klassen- 
hierarchie, Fiir eine Realisierung miissen entsprechende 
Subklassen von dieser Hierarchic abgeleitet werden. Das 
CIM definiert Klassen fur Objekte und Klassen fur Assozia- 
tionen. Das CIM wird von der sogenannten Desktop Mana- S 
gement Task Force (DMTF) festgelegt; genauere Informa- 
tionen findet man im Web unter http://wbem.frcerange.coni/ 
wbempdk. Beispiele fur im CUM definierte Objektklassen 
sind "Managed System Element", "Physical Container", 
"Physical Element" oder "Disk". Davon kann dann zum Bei- lO 
spiel eine Subklasse fiir eine spezielle Festplatte abgeleitet 
werden. Beispiele fiir Assoziaiionen sind "Components", 
"Dependency" oder "Contains". Fur ein konkretes Manage- 
ment miissen auch hiervon Subklassen abgeleitet werden. 
DaB CIM jedoch keineswegs das einzige mogliche Informa- 15 
tionsmodell ist, zeigt die Tatsache, daB JMAPI ein anderes 
Informationsmodell verwendet. 

Der Objckt-Manager OBJ-MGR bietet den Zugriff auf 
diese komplexen Objekte. £r wird gesteuert von den Defini- 
tionen der komplexen Objekte, die sich in der Datenbank 20 
DB befinden. Solche Definitionen konnen von den vorgege- 
benen CIM-Klassen abgeleitet und als sogenannte Managed 
Object Files MOF erzeugt werden. MOFs konnen iiber den 
MOF-Compiler in die Datenbank DB eingelesen werden. In 
der Datenbank DB kann der Objekt-Manager OBJ-MGR 25 
auch statische Objekte ablegen. Sowohl Applikationen wie 
auch Provider PROV greifen iiber das Protokoll HMMP 
(Hypermedia Management Protocol) auf-komplexe Objekte . 
zu. HMMP konununiziert komplexe Objekte und bietet un- 
ter anderem folgende Typen von.Operationen: ' " - 30 

- Manipulation von Klassen: Get, Delete, Put, Enume- 
rate 

- Manipulation von Instanzen: Get, Delete, Put, Enu- 
merate ~ " 35 

- Aufruf von Methoden: Execute. 

HMMP ist noch nicht als Draft RFC bei der IETF einge- 
reicht und es bleibt abzuwarten, ob sich dieser Standard 
durchsetzt. Bei der derzeitigen WBEM-Realisierung wird 40 
deshalb eine proprietare Kommunikation verwendet 
(JMAPI verwendet Java Remote Invocation Methode 
(RMD). 

Auch hier gilt, daB die Information, die verschiedene 
Applikationen benodgen, nicht unbedingt so strukturiert ist, 45 
wie das vom Objekt-Manager OBJ-MGR verwendete Infor- 
mationsmodell. Wenn eine Funktion einer Applikation auf- 
gerufen wird, so muB die von ihr benotigte Information im 
allgemeinen durch die Abbildungskomponente MAP2 auf 
die komplexen Objekte des Objekt-Managers OBJ-MGR 50 
abgebildet werden, bevor dann entsprechende HMMP Re- 
quest an den Objekt-Manager OBJ-MGR geschickt werden. 
(Nur ein MOF-Browser kommt ohne MAP2 aus.) Empfangt 
der Objekt-Manager OBJ-MGR einen solchen HMMP-Re- 
quest, dann versucht er zunachst, das Objekt aus der Daten- 55 
bank DB zu lesen. Ist dort das Objekt nicht abgespeichert, 
dann steht in der Datenbank DB die Information, uber wel- 
chen Provider PROV die Daten von der uberwachten Kom- 
ponente U-KOM abgerufen werden konnen. Der Objekt- 
Manager OBJ-MGR schickt darin einen HMMP-Request an 60 
diesen Provider. 

Da HMMP komplexe Objekte konununiziert, ist der wei- 
tere Ablauf folgendermaBen: Die Abbildungskomponente 
MAPI zerlegt die Anforderung nach einem komplexen Ob- 
jekt in entsprechende Anforderungen nach einfachen in ei- 65 
ner MIB definierten Objekten und schickt iiber den Proto- 
kollstack SNMP-PrSt entsprechende SNMP-Requesis an 
die uberwachte Komponente t)-KOM. Diese antwortet mit 
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sogenannten SNMP-Responses, deren Daten dann von dem 
Protokollstack SNMP-PrSt des Porviders PROV ausgepackt 
werden. Die Abbildungskomponente MAPI hat nun die 
Aufgabe, aus diesen Daten das entsprechende komplexe Ob- 
jekt zusammenzubauen und als Antwort auf den HMMP- 
Request an den Objekt-Manager OBJ-MGR zu schicken. 
Deshalb ist die Realisierung des Modules fiir die Abbil- 
dungskomponente MAPI sowohl von den MEBs wie auch 
von den Definidonen der komplexen Objekte in den MOFs 
abhangig. Der Objekt-Manager OBJ-MGR schickt die In- 
formation dann an die Applikation, wo die Abbildungskom- 
ponente MAP2 aus den komplexen Objekten die von der 
Applikadon angeforderte Informadon zusammenstellen 
muB. Beide Abbildungskomponenten MAPI und MAP2 
sind von den Definidonen der komplexen Objekte in den 
MOFs abhangig. 

Die Vorteile dieses Ansatzes bestehen darin, 

- dafi eine darauf aufgebaute Losung Informationen 
mit an deren Losungen iiber HMMP austauschen kann. 
Dieser Vorteil kommt jedoch nur dann zum TVagen, 
wenn HMMP ein genormtes Protokoll ist, 

- daB eine lokale Managemendosung auf einem allge- 
mein verwendbaren CIM-orienderten Framework 
(WBEM: WBEM Professional Developer's Kit) aufge- 
baut werden kann. 

Der Einsatz eines Objekt-Managers OBJ-MGR nut einem 
vorgegebenen Modell auf der Basis komplexer Objekte 
fuhrt jedoch auch zu folgenden Problemen: 

- Es ist zu beachten, daB auch bei Verwendung eines 
Frameworks fur jeden Provider PROV und jede Appli- 
kation zwei entsprechende Abbildungskomponenten 
MAP zu realisieren sind, die relativ komplex sind. 

- Weiterhin kann das zweimalige Mapping zwischen . 
iiberwachter Komponente U-KOM und der APPLIKA- 
TION zu Informationsverlusten fiihren und die Lei- 
stungsfahigkeit des Systems beeintrachtigen. 

- Es gibt nur statische und dynamische Objekte. Stati- 
sche Objekte werden in MOFs beschrieben und iiber 
den MOF-Compiler in der Datenbank DB abgespei- 
chert. Dynamische Objekte werden immer uber den 
Provider PROV angefordert. Eine flexiblere Bereitstel- 
luogs-Strategie wird nicht unterstutzt. 

Die Erfindung bezweckt nun, die genannten Nachteile der 
bekannten Losungen zu vermeiden. Bei einem Verfahren zur 
Durchfiihrung von Uberwachungs- und Managementfunk- 
donen in Netzen mit iiberwachten Komponenten gemaB 
dem Oberbegriff des Patentanspruches 1 wird dies durch die 
kennzeichnenden Merkmale dieses Anspruches erreicht. 

Bindegiied zwischen der Abfrageeinheit und den iiber- 
wachten Komponenten ist danach eine gesonderte Bereit- 
stellungseinheit mit einer relationalen Datenbank, in der alle 
einfachen Objekte gespeichert werden. Auf diese Weise ist 
es moglich, den Informadonsaustausch zwischen der rela- 
tionalen Datenbank und den uberwachten Komponenten in 
bekannter Weise mittels einfacher Objekte auszufuhren. An- 
dererseits kann die Abfrageeinheit mit Auswahlbefehlen der 
SQL-Sprache auf die Datenbank zugreifen und don gespei- 
cherte Managementdaten in beliebig auswahlbarer Kombi- 
nation abrufen. 

GemaB einer vorteilhaften Weiterbildung der Erfindung 
ist die Bereitstellungseinheit unabhangig von den in der je- 
weiligen Managemendosung verwendeten MIBs, da die in 
einer Datei (MIB+) enthaltenen und gegebenenfalls durch 
weitere Steuerfunktionen eiganzten Definitionen der ver- 
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wendeten einfachen Objekte ebenfalls in die relationale Da- 
tenbank (REL-DB) ubernommen werden und einerseits in 
der Initialisierungsphase den Aufbau der Tabellenstxukturen 
fiir die Managementxiaten (MGMT-DATA) steuem und an- 
dererseits als Steueranweisungen (META-DATA) fur die 5 
Bereitstellungseinheit (C&CM) die Bearbeitung der Aus- 
wahlbefehle (SQL-SELECT) ermogUchen. 

Weiterhin kSnnen den Objektdefinitionen Attribute als 
weitere Steuerfunktion beigefiigt werden, die beim Zugriff 
auf ein Objekt oder eine Objektgruppe festlegt, wie die Be- lO 
reitstellungseinheit bezuglich der Zurverfugungstellung der 
notwendigen Informationen fur einen AuswahlbefeU. zu 
reagieren hat. 

Analoges gilt fiir eine entsprechend gestaltete Anordnung 
entsprechend den Patentanspriichen 4 bis 6. 15 

Einzelheiten der Erfindung seien nachfolgend an Hand ei- 
nes in der Zeichnung dargestellten Ausfiihrungsbeispieles 
naher erlautert. Im einzelnen zeigen 

Fig, 1 das Prinzip einer SNMP-basierten Managementlo- 
sung gemaB dem Stand der Technik, 20 

Fig. 2 das Prinzip einer Managementlosung gemaB der 
WBEM-Architektur entsprechend dem Stand der Technik 
und 

Fig. 3 das Prinzip der Managementlosung gemaB der Er- 
findung. 25 

Die Figuren Fig. 1 und Fig. 2 sind bereits im Rahmen der 
Erlauterung des Standes der Technik beschrieben worden. 

Bei der Managementlosung gemaB Fig. 3 bildet eine Be- 
reitstellungseinheit C&CM mit einer relationalen Daten- 
bank REL-DB den Kern. Die Erfindung nutzt dabei die Tat- 30 
sache, daB relationale Datenbanken die Daten in Form von 
Tabellen abspeichem. Der Zugriff erfolgt uber Auswahlbe- 
fehle SQL-SELECT der SQL-Sprache, wobei durch die An- 
gabe von Bedingungen festgelegt wird, welche Daten der 
Auswahlbefehl SQL-SELECT liefert. Mit einem solchen 35 
Auswahlbefehl kann auch ein Zugriff auf eine Verknupfung 
von mehreren Tabellen erfolgen. Dabei werden durch den 
JOIN-Operator zwei Tabellen gemaB den angegeben Bedin- 
gungen miteinander zu einer neuen Tabelle verkniipft. 
Durch die Schachtelung von JOIN-Operatoren lassen sich 40 
im Prinzip beUebig viele Tabellen miteinander verkniipfen. 
Das Ergebnis eines SELECT-Statements ist schlieBlich wie- 
der eine Tabelle. tJberblick iiber SQL findet sich in Marc 
Adler, "Eine kurze Einfuhrung in die SQL-Sprache", Micro- 
soft System Journal: Special Database, HerbstAVinter 93. 45 

Eine weitere Basis der Erfindung ist die Idee, einfache 
Objekte 1 : 1 in der relationalen Datenbank abzuspeichem. 
Jede Applikation kann sich dann mit Hilfe von Auswahlbe- 
fehlen SQL-SELECT die Informationen aus der Datenbank 
holen, die sie benotigt. Dabei konnen Informationen pro- 50 
blemlos aus verschiedenen MIBs verkniipft werden, weil 
die Daten jeder MIB in Form einer oder mehrerer TabeEen 
in der REL-DB abgelegt sind. Zugleich kann die Bereitstel- 
lungseinheit C&CM mit der Datenbank REL-DB eine flexi- 
ble Caching-Strategie unterstutzen. 55 

Um die Aibeitweise einer solchen Managementlosung zu 
erklaren, werden im folgenden zwei Vorgange detaiUiert be- 
schrieben, namlich das Einrichten der Datenbank durch die 
Bereitstellungseinheit C&CM und eine SQL-Abfrage von 
einer AppUkation. 60 

Einrichten der relationalen Datenbank REL-DB: 
MIBs definieren in einer formalen Beschreibung die SNMP- 
Objekte. Es gibt sogenannte MEB-Compiler, die daraus Ta- 
bellen erzeugen, die geeignet sind, von Computerprogram- 
men gelesen und interpretiert zu werden. Fiir die Bereitstei- 65 
lungseinheit C&CM konnwi zu diesen vom MIB Compiler 
erzeugten Tabellen manuell weitere Objektmerkmale hinzu- 
gefugt werden, wie die Caching- Kategorie. Diese Ikbellen 



947 A 1 ^ 

6 

sind in Fig, 3 als MIB+ bezeichnet. Der Wert dieses Merk- 
mals bestimmt dann, wie die Bereitstellungseinheit C&CM 
Zugriffe auf dieses einfache Objekt behandelt. MIB+ enthalt 
also samtliche Informationen, die zum Einrichten der rela- 
tionalen Datenbank REL-DB benotigt werden. 

In der Initialisierungsphase liest die Bereitstellungsein- 
heit C&CM die MIB+ ein, richtet die Tabellenstrukturen fur 
die Managementdaten MGMT-DATA ein und legt die be- 
schreibende Information als META-DATA ab. META- 
DATA enthalt zum Beispiel fur jedes einfache Objekt die In- 
formation, wie in der relationalen Datenbank REL-DB dar- 
auf zugegriffen wird, wie uber SNMP darauf zugegriflFen 
wird, die Caching- Kategorie, usw. Durch die Informationen 
META-DATA ist die Implementierung der Bereitstellungs- 
einheit C&CM vollig unabhangig von den in der Manage- 
mentlosung verwendeten MIBs. Andererseits wird das Ver- 
halten der Bereitstellungseinheit C&CM von diesen Infor- 
mationen gesteuert, so daB die Bereitstellungseinheit 
C&CM nach dem Erzeugen dieser Informationen in der re- 
lationalen Datenbank REL-DB fur die Applikationen bereit 
ist. 

Abfrage durch die Applikation: 
Wird in einer APPLIKATION eine bestimmte Funktion auf- 
gerufen, fordert sie uber einen Auswahlbefehl SQL-SE- 
LECT an die Bereitstellungseinheit C&CM die benotigte In- 
formation an. Die Bereitstellungseinheit C&CM analysiert 
dann, welche der Managementdaten MGMT-DATA von 
dem Auswahlbefehl SQL-SELECT direkt oder indirekt 
durch eine SQL-JOIN-Operation betroffen sind. Weiterhin 
wird an Hand der zugehorigen Information META-DATA 
gepriift, ob auf die in der Datenbank bereits abgespeicherten 
Managementdaten MGMT-DATA zugegriffen werden kann 
oder ob diese erst von den iiberwachten Komponenten U- 
KOM anzufordem sind. Ist letzteres der Fall, dann sendet 
die Bereitstellungseinheit C&CM iiber den Protokollstack 
SNMP-PrSt entsprechende SNMP-Requests an die iiber- 
wachten Komponenten U-KOM und tragt die uber SNMP- 
Responses erhaltenen Daten MGMT-DATA in die Daten- 
bank REL-DB ein. Wenn alle betroffenen Daten vorliegen, 
laBt die Bereitstellungseinheit C&CM den Auswahlbefehl 
SQL-SELECT von der Datenbank REL-DB ausfiihren und 
liefert das Ergebnis an die APPLIKATION. 

Dieser Losungsansatz ist nicht darauf beschrankt, daB die 
iiberwachten Komponenten U-KOM die Managementdaten 
iiber SNMP liefert. Jede andere Form zur Ubertragung ein- 
facher Objekte - bestehend aus Name und Wert - kann ver- 
wendet werden. Ein anderes Beispiel ist DMI (Desktop Ma- 
nagement Interface), eine der DMTF (Desktop Management 
Task Force) genormte Schnittstelle zur Ubertragung von 
einfachen Objekten, die in MIFs (Management Information 
Files) definiert werden. 

Patentanspriiche 

1. Verfahren zur Durchfuhrung von tJberwachungs- 
und Managementfunktionen in Netzen mit uberwach- 
ten Komponenten (U-KOM) unter Verwendung einfa- 
cher, durch Name und Wert beschriebener Objekte fiir 
den Informationsaustausch zwischen den iiberwachten 
Komponenten (U-KOM) und einer Abfrageeinheit 
(ADMIN- KON), wobei die Informationen in beliebig 
ausgewahlter Kombination an der Abfrageeinheit pra- 
sentiert, verandert und zur Einstellung der iiberwachten 
Komponenten (t)-KOM) verwendet werden, dadurch 
gekennzeichnet, daB die Verbindung der Abfrageein- 
heit (ADMIN-KON) mit den iiberwachten Komponen- 
ten (U-KOM) uber eine gesonderte Bereitstellungsein- 
heit (C&CM) erfolgt, und daB der Informationsaus- 
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tausch zwischen der Bereitstellungseinheit (C&CM) 
und den iiberwachten Komponenten (U-KOMP) mit- 
tels einfacher Objekte erfolgt und alle diese Objekte in 
einer reLadonalen Datenbank (KEL-DB) der Bereitstel- 
lungseinheit (C&CM) gespeichert werden, wahrcnd 
die Abfrageeinheit (ADMIN-KON) mit Auswahlbe- 
fchlcn (SQL-SELECT) der SQL-Sprache auf die rela- 
tionale Datenbank (REL-DB) zugreifen und dort ge- 
speicherte Managementinformationen (MGMT- 
DATA) in beliebig auswahibarer Kombination abrufen 
kann. 

2. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dafi die in einer Datei (MIB+) enthaltenen und ge- 
gebenenfalls durch weitere Steuerfiinktionen erganzten 
Definitionen der verwendeten einfachen Objekte eben- 
falls in die relationale Datenbank (REL-DB) Qbemom- 
men werden und einerseits in der Initialisierungsphase 
den Aufbau der Tabellenstrukturen fur die Manage- 
mentdaten (MGMT-DATA) steuem und andererseits 
als Steueranweisungen (META-DATA) fiir die Bereit- 
stellungseinheit (C&CM) die Bearbeitung der Aus- 
wahlbefehle (SQL-SELECT) ermoglichen. 
. 3. Verfahren nach Anspruch 2, dadurch gekennzeich- 
net, daB als weitere Steuerfunktion den Objektdefini- 
tionen ein Attribut beigefugt ist, das beim Zugriff auf 
ein Objekt Oder eine Objektgruppe festlegt, wie die Be-. 
reitstellungseinheit (C&CM) bezuglich der Zurverfu- 
gungstellung der notwendigen Inforraationen fiir einen 
Auswahlbefehl (SQL-SELECT) zu rea§ieren hat. 

4. Anordnung zur Durchfuhrung von Uberwachungs- 
und Managementfunktionen in Netzen niit Uberwach- 
ten Komponenten (t)-KOM) unter Verwendung einfa- 
cher, durch Name und Wert beschriebener Objekte fiir 
den Informationsaustausch zwischen den uberwachten 
Komponenten (U-KOM) und einer Abfrageeinheit 
(ADMIN-KON) mit Einrichtungen zur^Prasentation 
der Informationen in beliebig ausgewahtter Kombina- 
tion, zur Anderung der Information und zur Einstellung 
der uberwachten Komponenten (0-KOM) an Hand 
vorgegebener Informationen, gekennzeichnet dutch 
eine gesonderte Bereitstellungseinheit (C&CM) mit ei- 
ner rclationalen Datenbank (REL-DB) zur Speicherung 
der Objekte, wobei die Bereitstellungseinheit (C&CM) 
mit den uberwachten Komponenten (0-KOM) liber 
Einrichtungen zum Informationsaustausch mittels ein- 
facher Objekte (S^^MP-PrSt) und mit der Abfrageein- 
heit (ADMIN-KON) iiber Einrichtungen zur Bereit- 
stellung von Managementdaten (MGMT-DATA) aus 
der relationalen Datenbank (REL-DB) in beliebig aus- 
wahibarer Kombination auf Grund von Auswahlbefeh- 
len (SQL-SELECT) der SQL-Sprache gekoppelt ist. 

5. Anordnung nach Anspruch 4, dadurch gekennzeich- 
net, daB die Bereitstellungseinheit (C&M) weiterhin 
Einrichtungen zur Obemahme der Objektbeschreibun- 
gen und zum Einrichten der entsprechenden Tabellen- 
strukturen in der relationalen Datenbank (REL-DB) fUr 
die Managementdaten (MGMT-DATA) in der Initiali- 
sierungsphase sowie zur Speicherung von Steueran- 
weisungen (META-DATA) fiir die Bereitstellungsein- 
heit (C&CM) zur Bearbeitung der Auswahlbefehle 
(SQL-SELECT) aufweist. 

6. Anordnung nach Anspruch 5, gekennzeichnet durch 
Einrichtungen zur Auswerlung eines der jeweiligen 
Objektdehnition beigefugten Attributs als weitere 
Steuerungsfunkdon zur Beeinflussung der Bereitstel- 
lungseinheit (C&CM) bezuglich der zur Verfugung- 
siellung der fiir einen Auswahlbefehl (SQL-SELECT) 
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benotigten Managementdaten (MGMT-DATA). 
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